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Description 

Original Transcript System: Method and 
System to issue, submit and view 
original electronic transcripts. 

Background of Invention 
Field of Invention 

[0001] a transcript in OTS is any electronic file that includes a 
PDF file, word file or image file. Transcripts are issued by 
the issuer and are, original copies of documents main- 
tained by the issuer, or a collection of information from 
various sources maintained by the issuer. 

[0002] Examples: An employment verification letter is a tran- 
script. A passport book is a collection of transcripts where 
each page is a transcript. A university mark sheet sum- 
mary is a transcript. 

[0003] some examples of processes that require transcripts are... 

[0004] process: Apply for a loan. Transcripts: Bank statement, 
Verification of employment. 



[0005] process: Obtain auto insurance from an insurance com- 
pany. Transcripts: Driving License, Proof of vehicle owner- 
ship. 

[0006] process: Apply to graduate school. Transcripts: Under- 
graduate transcripts, Recommendation letters. 

[0007] process: Apply for visa. Transcripts: Passport, Birth certifi- 
cate. 

[0008] process: Enter a country. Transcripts: Passport, Visa. 

[0009] OTS provides a secured way for all involved parties, to log 
on to the OTS system for their transcript needs. Using 
OTS, an issuer can issue a transcript to the applicant, an 
applicant can receive an issued transcript from the issuer 
and submit it to a reviewer. An Issuer, applicant or re- 
viewer of a transcript can view the transcript. 

[0010] when all involved parties(issuer, applicant, reviewer) for a 
process are on OTS, it will eliminate the need to, submit in 
person, snail post or e-mail, supporting transcripts to 
complete that process. Storage of originals in any form 
electronic or paper by the applicant and reviewer will also 
be eliminated. 

[001 1] As an example Company XYZ, company ABC and individ- 
ual Peter are all registered on OTS, and use OTS for Peter's 
transcript. The process is a background check by ABC on 



Peter's prior employment with XYZ. The transcript is re- 
lieving letter issued by XYZ for Peter. 

[0012] Peter's previous company XYZ logs in to OTS and issues 
the relieving letter to Peter. Peter logs in to OTS submits 
the received relieving letter to company ABC. ABC logs 
into OTS and views Peter's relieving letter, using it in the 
background check process. 

[0013] There is no e-mail or paper based exchange involved. 

When ABC or Peter wants to view the transcript it is trans- 
ferred from XYZ. There is no storage and maintenance of 
the original transcript issued by company XYZ, at com- 
pany ABC or Individual Peter. 
Description of related art 

[0014] The process of submitting an original document is one of 
most cumbersome activities, be it through paper or e- 
mail. 

[0015] Paper based transcripts: Original transcripts are lost, and 
needs to be issued again. Also often original transcripts 
cannot themselves be sent out. A notarized or attested 
copy of the original is sent out after submitting the origi- 
nal before a notary. Hence submitting these paper based 
transcripts can be delayed and can even end up in an ap- 
plication getting cancelled for lack of originals. Also origi- 



nal transcripts when received could be cleverly forged, 
and are needed to be verified for authenticity. 

[0016] Digital Signature: Digital signatures, needs public keys 
also to be transferred besides the digitally signed docu- 
ment. Also a reviewer of a digital document needs to 
know the public key, sent by the issuer to the applicant. If 
the public key is lost, or the certificate is revoked, the 
whole process of sending transcripts by e-mail and public 
keys must be carried out again. Additionally once the 
public key is known any receiver can read a digitally 
signed document. 

[0017] Organizing transcripts: In both the paper based and digi- 
tally signed transcripts, issuers and receivers have to indi- 
vidually file them based on the issuers, applicants and re- 
viewers. They have to maintain a list to who all a tran- 
script was issued, or from who all a transcript was re- 
ceived from. There is a lot of manual work involved to or- 
ganize these transcripts even after the identity is con- 
firmed. 

[0018] OTS overcomes these difficulties by providing secure 

identity, secure content, with no maintenance required by 
an applicant or reviewer for transcripts. 

[0019] The transcripts are issued by the issuer, and sent to the 



applicant. An applicant can decide to whom that transcript 
in turn needs to be submitted for review. The original 
transcripts are always requested from the issuer when at- 
tempted to be viewed by an applicant or reviewer. A re- 
viewer can receive a transcript from the issuer only if sub- 
mitted to the reviewer by the applicant. 
[0020] This provides the ability for the issuer to just delete the 
transcript, and thus end any future views of that original 
transcript. The control of a transcript by the issuer need 
not depend on the interaction with a third party, to revoke 
certificates. 

[0021] OTS provides a secure view for transcripts. Transcripts are 
always generated by the issuer and transferred from the 
issuer to an applicant or reviewer in a secure medium. 

[0022] issuer, identity is guaranteed on any transcript in OTS, 

digitally signed or not. In cases where transcripts are digi- 
tally signed, the OTS - Digital Signature combination acts 
as a double identity assurance of the issuer. 

[0023] when a transcript is issued through OTS, the issuer knows 
that the recipient is the person who requested the tran- 
script. The applicant also knows who sent the transcript. 
The reviewer knows who the issuer and applicant of a 
transcript is. 



[0024] OTS eliminates storing transcripts at the applicant and re- 
viewer area. Users can retrieve transcript information for 
which they have a role, by search parameters that include, 
time issued, time received, user, description, role, file 

name. 
Summary of Invention 

[0025] OTS is a system where users log in to their respective 

transcript servers, for their transcript needs that commu- 
nicate with each other through the transcript network 
server The transcript servers are distributed and must be 
able to reach the transcript network server through the 
Internet. 

[0026] An issuer issues a transcript to a unique user identifier 
(e.g. SSN or a company web site), name An applicant re- 
ceives this issued transcript from the issuer, views it and 
submits to a company using the unique user identifier 
(e.g. company web site name). A reviewer receives this 
transcript from the applicant. 

[0027] whenever a transcript is issued, or submitted only the en- 
velope for transcript (EFT) is passed to the receiver. When 
a transcript is viewed the actual transcript is sent from the 
issuer to the receiver. 

[0028] Original Transcript System, (OTS) is a identity secure, con- 



tent secure and organized means to issue and receive 
original transcripts. 

[0029] Transcript in OTS refers to any electronic file that can in- 
clude a PDF document, word document or an image file. 

[0030] a user can register as a company or an individual to the 
OTS system by providing an unique user id (UUID). A reg- 
istered user is assigned an OTS-ID that ties the user to 
the registered server and is unique on the entire system. 
This OTS-ID acts as the address for a user on the OTS 
system. A user can log in to the registering server using a 
user name local to the registering server and mapped to 
the OTS-ID. 

[0031] The OTS system is made of transcript servers and tran- 
script network server. The communication between tran- 
script servers is through the transcript network server. 
The transcript provider provides public/private key pairs 
to each server on OTS. This causes a virtual private tran- 
script network (VPTN), which enables only authorized 
transcript servers to communicate with each other. 

[0032] a transcript server (TS) does authentication of client sys- 
tems. It also sends out envelope for transcript (EFT) to 
other OTS-IDs, stores EFT received from other OTS-IDs, 
receives transcripts from an issuer and forwards it to an 



authorized client to complete a view request. 
[0033] The transcript network server (TNS) works with the tran- 
script servers to complete a user registration. Upon com- 
pletion the transcript network server assigns an OTS-ID 
unique in the system to the registered user. It also ties the 
registered user to the transcript server the user registered 
on. The transcript network server maintains a mapping 
between registration information and OTS-IDs. It also 
maintains a mapping between OTS-ID and hosting tran- 
script server. 

[0034] Companies can own their own transcript servers. Individ- 
ual can use transcript servers owned by the transcript 
provider. A transcript server must get access codes from 
the TP to communicate with OTS-IDs on another tran- 
script server. 

[0035] users talk to their transcript server using clients. A client 
is an application that provides the user interface to talk to 
the transcript server in a secured manner. This client ap- 
plication can be a stand alone application running on the 
user's desktop or a application loaded from the transcript 
server in a web browser. 

[0036] OTS defines roles for a user on a transcript. A user regis- 
ters as a Company or Individual. A company user or indi- 



vidual user must be able to clear a background check to 
complete registration and have an OTS-ID assigned by the 
transcript network server for that user. 

[0037] only a company user can create a transcript. A transcript 
is created by the company user entering the transcript 
server as issuer and moving the transcript to the tran- 
script server or providing a link file on the transcript 
server that points to the transcript on a remote computer 
system accessible from the transcript server. This com- 
pany becomes the issuer for the transcript. When the is- 
suer issues this transcript to another user, the recipient 
user becomes the applicant. The applicant can in turn 
submit this transcript to a company other than the issuer, 
for review. This company becomes the reviewer for the 
transcript. An individual user can only act as an applicant. 
A company user can act in one of the roles of issuer, ap- 
plicant or reviewer for a transcript. Any user that has roles 
on a transcript can view that transcript. 

[0038] when a transcript is issued or submitted only the EFT in- 
formation is sent. 

[0039] when a transcript is viewed it always comes from the is- 
suer. This enables the issuer to stop issuing a transcript 
just by deleting the transcript from the issuer path on the 



issuer's transcript server. If the issuer owns the whole 

transcript server the issuer can turn of communication to 

the system and disable access to all transcripts on that 

transcript server. A user need not rely on a third party to 

revoke certificates on individual transcripts. 

[0040] OTS eliminates the need to e-mail transcripts or snail post 

transcripts. OTS eliminates the need to store original 

transcripts by the applicant or reviewer. This is because a 

transcript viewed by the applicant or reviewer using OTS is 

always generated from the issuer and is original, secure 

and role identity guaranteed. 
Detailed Description 

Description: Preferred Embodiment 

[0041] The OTS system contains transcript servers, and the tran- 
script network server. Transcript servers talk to each other 
through the transcript network server, and are the servers 
that users log on to for their transcript needs. 

[0042] Transcript Server (TS) : 

[0043] TS enables a user to register with the OTS system. TS 
transfers the registration information to the transcript 
network server (TNS). TS receives from the TNS an OTS-ID 
for the user. OTS-ID is the address provided by the tran- 



script network server for a user. This address is unique 
throughout the system and ties the user to a transcript 
server and registration information. Upon receiving the 
OTS-ID for the user, TS stores the registration information 
for the user, the user's OTS-ID, creates a user name and 
password and provides the user name and password to 
the user. The user can from now on log in to the register- 
ing TS using the user name and password. 

[0044] Transcript servers always talk to the transcript network 

server. Each communication contains a sender OTS-ID and 
a receiver OTS-ID. 

[0045] Transcript Network Server (TNS) : 

[0046] when registration request is received from a transcript 

server for a user, TNS registers the user to OTS. The reg- 
istration information received by TNS must clear a back- 
ground check, performed by the transcript provider. After 
the background check is cleared TNS assigns a OTS-ID for 
a user, and ties this OTS-ID to the registration informa- 
tion and the registering transcript server. 

[0047] tns maintains the following information for identifying a 
user by the unique identifier and location of the TS host- 
ing the user, a mapping between unique user id like SSN 
or company web site name and the OTS-ID, and a map- 



ping between OTS-ID and hosting transcript server. 
[0048] pig 1 shows the steps involved when a user registers to 
the OTS. 

[0049] a transcript server communicates with other transcript 
servers through the transcript network server. The com- 
munication involves two phases. The first phase involves 
asking the transcript server the OTS-ID for a user inputted 
unique user id of the recipient. Once the OTS-ID is got 
from the TNS, the sending TS sends another message that 
has sender and receiver OTS-ID. The transcript network 
server receives this message, finds the transcript server 
hosting the receiver OTS-ID and forwards this message to 
the transcript server hosting the receiver OTS-ID. 

[0050] pig 2 shows the steps involved when two transcript 

servers communicate with each other through the TNS. 

[0051] Transcript provider (TP) : 

[0052] The transcript provider is an administrative person who 
maintains the OTS system. The transcript provider pro- 
vides private keys to each transcript server and the tran- 
script network server. The transcript provider also pro- 
vides the transcript servers with the public key of the 
transcript network server, and the transcript network 
server with the public keys of all transcript server it com- 



municates with. 

[0053] The transcript provider authenticates a user during regis- 
tration and validates the registration information. Upon 
success, the TP directs the transcript network server to 
assign a OTS-ID unique on the system for the user. 

[0054] Definitions: 

[0055] User Types: (Company/Individual): 

[0056] a user on OTS is either a Company or an Individual. A 

company is one who owns a transcript server and logs on 
to that transcript server after registering to OTS with 
company information (e.g. EIN or web site name). An indi- 
vidual is one who uses a transcript server maintained by 
the transcript provider and logs on to that transcript 
server after registering to OTS with individual information 
(e.g. SSN or passport number). 

[0057] Roles: (issuer/applicant/reviewer) : 

[0058] issuer, applicant and reviewer are the possible roles a user 
has on a transcript 

[0059] issuer: Issuers are always company users. When a com- 
pany creates a transcript, it becomes the issuer of the 
transcript. An issuer can issue this transcript to another 
company user or individual user. 



[0060] Applicant: Applicants are either company users or individ- 
ual users. When a transcript is issued to a company or in- 
dividual, the recipient user becomes the applicant. An ap- 
plicant can in turn submit the issued transcript to a com- 
pany user who is not the issuer. 

[0061] Reviewer: Reviewers are always companies users. A com- 
pany to which the applicant submits a transcript becomes 
the reviewer. 

[0062] Action: (issue/submit/view) 

[0063] issue: 'Issue' refers to the act of an issuer issuing a tran- 
script to an applicant. 

[0064] Submit: 'Submit' refers to the act of an applicant submit- 
ting a transcript to a reviewer that was previously issued 
to the applicant. 

[0065] view: All users related to a transcripts can view that tran- 
script. 

[0066] During a Issue or Submit .transcript servers do not send 

the actual transcript but instead send the envelope for 

transcript (EFT) information only. 
[0067] when a view request occurs on a transcript by the issuer, 

applicant or reviewer the transcript is sent from the issuer 

path to the viewer. 
[0068] pig 3 provides a figurative representation for user types, 



roles and actions. 
[0069] storage on Transcript servers: 

[0070] registration-table: The registration-table contains an en- 
try for each user and maps the registration information to 
the OTS-ID and user name/password for the user on the 
transcript server. 

[0071] <OTS-ID>-table: A transcript is always linked to a con- 
tainer name. The container name can refer to one or more 
transcripts. Each user has a <OTS-ID>-table created on 
the TS that stores container names associated with the 
user's OTS-ID. This container name is called the Root 
Transcript Location (RTL). 

[0072] <RTL>-transfer-table: For every RTL in the system there 
is a corresponding transfer table called 
<RTL>-transfer-table. The RTL table contains a list of 
transcripts, the roles associated with each transcript, a lo- 
cation called a local path for which a client invokes a view 
request and a location called remote path and remote 
OTS-ID that will actually serve this view request. If the re- 
mote path and remote OTS-IDs self, then the transcripts 
are actually present as a file in the file system under the 
local path. This file is the actual transcript file or a link to 
the actual transcript file that is accessible from the tran- 



script server. 

[0073] a transcript can be created only by a company user. When 
a transcript is created, the TS creates an RTL name, which 
is unique to the transcript server (e.g., timestamp) and as- 
signs the sender OTS-ID for the RTL as self. It also up- 
dates the <OTS-ID>-table for the user with this RTL 
name. This RTL is owned by OTS-ID if the sender is self in 
the <OTS-ID>-table. Only a owner OTS-ID can create files 
under the owned RTL. The transfer table for this RTL will 
contain all local paths to actual locations in the file system 
and all remote paths and remote OTS-IDs will be self. 

[0074] when a transcript is issued or submitted the sending tran- 
script server finds the recipient OTS-ID for a recipient 
unique user identifier from the transcript network server 
and sends out the envelope for transcript (EFT) informa- 
tion in a Original Transcript Message (OTM) to the tran- 
script network server. This EFT sent out contains the RTL 
name, RTL description, sender OTS-ID, receiver OTS-ID, 
local path for each transcript, description for each tran- 
script, and roles associated with each transcript. 

[0075] The transcript network server finds the appropriate host- 
ing transcript server for the receiver OTS-ID in the OTM 
and sends this to the recipient transcript server. 



[0076] The recipient transcript server receives this OTM with the 
following details. RTL name = <RTL>, sender OTS-ID = 
<sender OTS-ID>, one or more file path = <RTL>/<file 
name>. 

[0077] when this OTM is received the receiving TS creates a new 
RTL with the name. RTL name = <RTL>@<sender OTS- 
ID> and updates the <receiver OTS-ID>-table with this 
RTL name and sender field as <sender OTS-ID> for this 
RTL. It then proceeds to update the <RTL>@<sender 
OTS-ID>-transfer-table. 

[0078] | n the transfer table all the file paths got from the OTM go 
as remote paths and the, <sender OTS-ID> is the remote 
user The local paths are created from the remote path, by 
replacing the RTL name portion with the RTL name for this 
transfer table. In other words <RTL>/<file name> be- 
comes the remote path, <sender OTS-ID> becomes the 
remote user and <RTL>@<sender OTS-ID>/<file name> 
becomes local path in <RTL>@<sender OTS- 
ID>-transfer-table. 

[0079] pig 4, shows how RTLs form between OTS-IDs during is- 
sue, and submit actions. 

[0080] storage at Transcript network server: 

[0081] uUID-OTSID-TS-table. 



[0082] This table contains a mapping between unique identifiers, 
like SSN, the UUID type that identifies if it is a SSN, pass- 
port number, etc, and the corresponding OTS-ID. This ta- 
ble also contains the transcript server host name. 

[0083] Global-Registration-Table. 

[0084] This table contains the registration information for each 
OTS-ID. The UUID provided by the user is also a part of 
the registration information. The UUID-OTSID-table is 
built out of the Global-Registration-Table. 

[0085] OTS-Display-Table. 

[0086] a user during registration can choose to expose some of 
the users personal information to other users on OTS (e.g. 
first name and e-mail address). This table contains the 
mapping between OTS-ID and display information. 

[0087] TS-Status-table. 

[0088] This table maintains the list of active transcript servers. 
The TNS does not forward OTMs to inactive transcript 
servers. 

[0089] Reliable communication: 

[0090] The communication between the transcript server and TNS 
is reliable. When a TS sends an OTM to the TNS, the TNS 
forwards it to the destination TS. When the destination TS 



receives this message it acknowledges the receipt to TNS. 
After a receipt the TNS tells the sending TS that the OTM 
has successfully reached the destination. If the destination 
TS is not up or does not acknowledge the successful re- 
ceipt of a OTM the TNS responds with a failed receipt to 
the sending TS. 
[0091] OTM. 

[0092] Messages between TS that go through the TNS are called 
OTM (Original Transcript Messages). 

[0093] EFT OTM : This is the OTM that carries envelope for tran- 
script (EFT) details from sender OTS-ID to a receiver OTS- 
ID. When the TNS receives an OTM of type EFT it gets the 
receiver OTS-ID present in the EFT OTM, and sends the 
EFT OTM to the transcript server hosting the receiver 
OTS-ID. 

[0094] pig 5 shows the contents of an EFT OTM for issue and 
submit actions. Refer Fig 4 also to get details of users, 
transcript servers and stored table values. 

[0095] view OTM: When a view request comes for a local path 
and if the remote path is not self, the transcript server 
builds a view OTM that has Interested location (the local 
path), Interested OTS-ID (the OTS-ID of the user who re- 
quested the view), sender OTS-ID (the OTS-ID that sends 



out this view OTM) and receiver OTS-ID (the OTS-ID men- 
tioned as remote on the transfer-table) and receiver loca- 
tion(the path mentioned as remote on the transfer-table). 
This view OTM is received by the TNS and forwarded to 
the TS hosting the receiver OTS-ID. 

[0096] pig 6 shows the contents of a View OTM for a view request 
by the applicant or reviewer. Refer Fig 4 also to get details 
of users, transcript servers and stored table values. 

[0097] Transfer OTM : 

[0098] The view OTM ends when sent to an issuer. The issuer 

sends out a transfer OTM which contains the actual tran- 
script, sender OTS-ID=issuer OTS-ID, receiver OTS- 
ID=interested OTS-ID and interested location on receiver. 

[0099] The TNS receives this transfer OTM and sends it to the TS 
hosting the receiver OTS-ID. The TS gets the transcript 
and gives it to the client waiting at the interested location, 
to complete the view request. 

[0100] pig 7 shows the contents of a transfer OTM sent from is- 
suer to viewer to complete a view request. Refer Fig 4 also 
to get details of users, transcript servers and stored table 
values. 

[° 101 ] Display OTM: 



[0 1 02] A TS sends a display OTM to the TNS providing an OTS-ID. 
The TNS returns with the display name for that OTS-ID 
that includes personal information classified as display by 
the user, (e.g., First name and e-mail address). 

[0 1 03] Look up OTM: 

[0104] a look up OTM is sent from a TS to the TNS contains the 
UUID information. The TNS responds back by providing 
the OTS-ID for the UUID information to the requesting TS. 

[0105] identity and Content Security: 

[0106] VPTN : 

[0107] The virtual private transcript network is created by as- 
signing public/private keys to each server in OTS. Each 
transcript server has the public key of the transcript net- 
work server. The transcript network server maintains a list 
of public keys for all transcript servers, on the system. 

[0108] Any OTM sent by the TS is encrypted with the private key 
of the transcript server. 

[0109] when a OTM is received from a transcript server. The TNS 
finds the originating host name for the message. It then 
queries its tables and decrypts the message with the pub- 
lic key, got corresponding to the transcript server host 
name, if the message is not decrypt able it ignores the 



message. After the message is decrypted it confirms if the 
sender OTS-ID belongs to the sending transcript server. 
The TNS then encrypts this message with the private key 
of the TNS and sends it out to the TS hosting the receiver 
OTS-ID. 

[0110] The receiving transcript server, decrypts the message with 
the TNS public key. 

Fig 8 shows the secured communication between TS and 
TNS which forms the Virtual private transcript network 
(VPTN) for OTS. 

[0112] a company owns a transcript server, and gets the keys 
from the transcript provider. Individuals are associated 
with transcript servers owned by Transcript Provider 

[0113] OTS-ID acts as the address for a user and ties the user to 
a transcript server and the user's UUID. Hence role identity 
on a transcript is always guaranteed. 

[0114] Transcripts are not stored on reviewer or applicant. An is- 
suer's RTL name maps to a location in the file system, that 
can contain the transcript or a link to the file accessible by 
the transcript server. 

[0115] a view OTM from an OTS-ID who is the reviewer , received 
by another OTS-ID who is the applicant is forwarded to 
the issuer only if the sender OTS-ID is a reviewer to that 



transcript.. Also an issuer accepts view OTMs only from an 
applicant of the transcript 

[0116] a incoming transfer OTM is accepted only if the issuer 

role on the transcript matches with the sender OTS-ID in 
the transfer OTM. 

[0117] A n ETM is not forwarded by the TNS if the hosting tran- 
script server does not host the sender OTS-ID in the ETM. 
Operation: Preferred Embodiment 

[0118] The operation of OTS can be best explained with a real life 
"like" scenario. 

[0119] operation of OTS is not limited to the particular scenario 
below, but rather can operate wherever there is a need to 
issue, receive or view original transcripts, by users of OTS. 

[0120] john Turner is employed with Tecoi Systems, and needs a 
loan to buy a home. 

[0121] He applies for a loan to lenders Bank Of Trust and Loan 

Pal. The lenders need John to submit a verification of em- 
ployment (VOE) from Tecoi Systems. Tecoi Systems issues 
a VOE transcript to John "using OTS". John submits this 
transcript using to Bank Of Trust and Loan Pal, "using 
OTS". Bank Of Trust views John's VOE "using OTS". Loan 
Pal views John's VOE "using OTS". After view of John's VOE, 
Bank Of Trust finds John's salary insufficient and responds 



unfavorably to John's request. But Loan Pal finds John's 
salary to meet their requirements and needs a savings ac- 
count statement to complete the review of John's loan ap- 
plication. Contra Bank issues John his savings account 
statement "using OTS". John submits this transcript to 
Loan Pal "using OTS". Loan Pal views John's savings ac- 
count statement "using OTS". Loan Pal decides favorably 
and invites John to sign the necessary papers. After this 
Loan Pal prepares a transcript and issues it to John "using 
OTS". John submits this Loan transcript to IRS as he needs 
a tax rebate on his loan. IRS views John's Loan transcript 
"using OTS" and grants the rebate. 

[0122] All users are registered to their respective transcript 
servers The transcript servers can talk to each other 
though the transcript network server. 

[0123] pig 9, details the name of each user, the OTS-ID for each 
user, the transcript server that the OTS-ID is assigned to, 
and the registration type (Individual or Company) for each 
user. 

[0124] pig 10, refers to the OTS state diagram for this particular 
scenario. 

[0125] The oval figures are transcript servers. An OTS-ID is men- 
tioned inside the transcript server because that OTS-ID is 



hosted by the transcript server. The transcript servers in- 
volved in this scenario are those oval figures with a con- 
tinuous line. The transcript servers not involved in this 
scenario are those oval figures with a dashed line. The 
figure shows three types of small squares. This means 
that there are three separate transcript chains involved. 
(VOE, Account Statement and Loan). The top of the square 
refers to the state when a transcript is received. The bot- 
tom of the square refers to the state when a transcript is 
sent. These states are also numbered in sequence with 
dotted lines pointing to the top and bottom of the small 
squares. 

[0126] Tecoi Systems has prepared the PDF VOE.pdf for John. 

[0127] Tecoi Systems logs into transcript server(TS): 

tecoisys.ots.com and is recognized by its TS as OTS-ID 
tecoisys. tecoisys enters as issuer, tecoisys creates the 
VOE.pdf on tecoisys.ots.com. This file can be created by 
transferring the actual transcript to the TS or by creating it 
as a link on the TS that points to the actual file located in 
another computer system and accessible from 
tecoisys.ots.com. tecoisys chooses to transfer the actual 
file. 

[0128] state 1: Refer to Fig 11: When transcript server: 



tecoisys.ots.com receives a transcript from tecoisys, it 
creates an RTL 0228200410345400, which is a directory 
and stores VOE.pdf under this RTL. It then proceeds to 
update tecoisys-table and 
0228200410345400-transfer-table. 
[0129] state 2: Refer to Fig 11: Once the transfer is complete 

tecoisys can now issue VOE.pdf to a UUID. tecoisys inputs 
john's SSN, which it already has in its employee records 
and issues the transcript, tecoisys updates the description 
for that RTL and description for the file under the RTL as 
"VOE for John Turner", then 'issues' the transcript VOE.pdf 
to the UUID for John. A look up OTM is sent by 
tecoisys.ots.com for the UUID to the TNS. The TNS re- 
sponds by providing OTS-ID as john76. tecoisys.ots.com 
updates the 0228200410345400-transfer-table with role 
information as tecoisys:issuer, john76:applicant. It con- 
structs an EFT OTM and sends it out to the TNS. The TNS 
receives this EFT OTM, and forwards it to the TS hosting 
john76. 

[0130] state 3: Refer to Fig 12: John Turner logs into transcript 
server:cadenizen. ots.com and is recognized as OTS-ID 
john76. He can only enter as an applicant, because his 
registration is of Individual status. He sees that a RTL has 



arrived from tecoisys with description "VOE for John 
Turner", from sender tecoisys. He clicks that RTL to see 
more information, and finds a link that says VOE.pdf, de- 
scription "VOE for John Turner", role information says 
tecoisys:issuer, john76:applicant. 

[0131] when John clicks on this link, view OTMs are generated 
that reach tecoisys.ots.com. tecoisys.ots.com responds 
with a transfer OTM that is received by cadenizen.ots.com. 
John's client application waits on the path for VOE.PDF. 
This local path also matches the Interested path in the re- 
ceived transfer OTM. cadenizen.ots.com gives the tran- 
script to the client waiting on the local path, to complete 
the view request. 

[0132] state 4: Refer to Fig 12: John 'submits' the transcript 

VOE.PDF to lenders with UUIDs, www.bankoftrust.com and 
www.loanpallenders.com by clicking on the submit button 
next for VOE.PDF. 

[0133] cadenizen.ots.com sends out look up requests to TNS for 
both the UUIDs. When the OTS-IDs are received it updates 
the RTL-transfer-table with role information as 
tecoisys:issuer, john76:applicant, bankoft: reviewer, loan- 
pahreviewer. cadenizen.ots.com sends EFT OTMs to re- 
ceiver OTS-IDs loanpal and bankoft, which are received by 



the TNS and forwarded to their respective transcript 
servers. 

[° 134 ] State 5: Refer to Fig 13: Bank Of Trust logs in to transcript 
server bankoft.ots.com and is recognized as OTS-ID 
bankoft by its transcript server, bankoft enters as re- 
viewer. It has received a RTL from john76 for which 
bankoft is the reviewer, bankoft clicks on the RTL and 
sees a link for file VOE.PDF. bankoft views the transcript 
by clicking on the link which generates view OTMs re- 
ceived by cadenizen.ots.com. cadenizen.ots.com in turn 
finds the issuer OTS-ID and location (remote OTS-ID and 
remote location) and sends an view OTM which is received 
by tecoisys.ots.com. tecoisys.ots.com responds with a 
transfer OTM that is received by bankoft.ots.com. 
Bankoft's client application waits on the local path for 
VOE.PDF on bakoft.ots.com. This local path also matches 
the Interested path in the received transfer OTM. 
bankoft.ots.com gives the transcript to the client waiting 
on the local path, to complete the view request. 

[0135] B an |< 0 f trust does not find John's salary to satisfy their 
minimum requirements for a loan. Bank of trust tele- 
phones, e-mails or snail mails John denying him the loan. 

[0136] state 6: Refer to Fig 14: Loan Pal logs in to transcript 



server loanpal.ots.com and is recognized as OTS-ID loan- 
pal by its transcript server, loanpal enters as reviewer. It 
has received a RTL from john76 for which loanpal is the 
reviewer, loanpal clicks on the RTL and sees a link for file 
VOE.PDF. loanpal views the transcript by clicking on the 
link which generates view OTMs received by cad- 
enizen.ots.com. cadenizen.ots.com in turn finds the issuer 
OTS-ID and location (remote OTS-ID and remote location) 
and sends an view OTM which is received by 
tecoisys.ots.com. tecoisys.ots.com responds with a trans- 
fer OTM that is received by loanpal.ots.com. loanpal's 
client application waits on the local path for VOE.PDF on 
loanpal.ots.com. This local path also matches the Inter- 
ested path in the received transfer OTM. loanpal.ots.com 
gives the transcript to the client waiting on the local path, 
to complete the view request. 

[0137] |_ oan pal finds John's salary to meet their minimum re- 
quirements for a loan. Loan Pal telephones john, e-mails 
or snail mails him and requests John provide them a sav- 
ings account bank statement. 

[0138] state 7: Refer to Fig 15: Contra bank logs into transcript 
server contrab.ots.com and is recognized as OTS-ID con- 
trab. contrab enters as issuer and creates a file Ac- 



count.PDF and transfers it to contrab.ots.com. When the 
TS receives this file it creates an RTL 0301200411234560 
and assigns this file under the RTL. The transcript table is 
updated with role information as contrab:issuer 

[° 139 ] State 8: Refer to Fig 15: After this contrab proceeds to 'is- 
sue' this transcript to John's UUID. contrab.ots.com re- 
quests the OTS-ID for John's UUID. When this OTS-ID is 
received contrab updates the transfer table. The role in- 
formation in the transfer table reads contrab:issuer, 
john76:applicant. contrab.ots.com creates a EFT OTM and 
sends it out to the TNS. 

[0140] The TNS receives this OTM and forwards it to cad- 
enizen.ots.com for OTS-ID john76. 

[° 141 ] State 9: Refer to Fig 16: At cadenizen.ots.com john76 now 
sees two RTLs. The previously received RTL from tecoisys 
and the newly arrived RTL from contrab. The transfer table 
has roles for file Account.PDF as contrab:issuer, 
john76:applicant. 

[0142] j 0 hn views this transcript. This causes view OTMs to go to 
contrab.ots.com and contrab.ots.com replies with the 
transcript for john76's local path by sending a transfer 
OTM. 

[0143] state 10: Refer to Fig 16: John76 now chooses the Ac- 



count.PDF link under this RTL and submits it to 
www.loanpallenders.com. cadenizen.ots.com gets the 
OTS-ID for the website from TNS and updates the transfer 
table with role information, contrab:issuer, 
john76:applicant,loanpal:reviewer. It creates an EFT OTM 
for OTS-ID loanpal and sends it to the TNS, which for- 
wards this OTM to TS loanpal.ots.com for OTS-ID loanpal. 
[0144] state 11: Refer to Fig 17: loanpal enters as reviewer. There 
are two RTLs from OTS-ID john76. One that has descrip- 
tion, VOE for John Turner and the other that has descrip- 
tion "Account Statement For John Turner", loanpal clicks 
the RTL for account statement and sees the Account.PDF 
link in it. When loanpal clicks this link view OTMs are sent 
from loanpal.ots.com bound for OTS-ID john76 and a lo- 
calpath on cadenizen.ots.com. But since this local path in 
turn refers to the issuer path as remote, cad- 
enizen.ots.com sends out a view OTM to contrab.ots.com 
and OTS-ID contrab. Contrab.ots.com receives the inter- 
ested local path, finds that the remote is self and sends a 
transfer OTM to loanpal and the local path for account.pdf 
on loanpal. 

[0145] Loanpal has all the information for john76's loan. He in- 
vites john to complete the formalities and enters as issuer 



and transfers file Loan. PDF, to loanpal.ots.com. This is the 
transcript of loan details for john turner from Loan pal. 
[0146] state 12: Refer to Fig 18: loanpal.ots.com creates a new 
RTL 0401200409002000 and assigns file Loan. PDF under 
this RTL. The transfer table has roles for this file as loan- 
pahissuer. 

[0147] state 13: Refer to Fig 18: loanpal proceeds to issue this 
file to John's UUID. loanpal.ots.com updates the transfer 
table with the OTS-ID for john got from TNS. The roles for 
Loan. PDF is updated as loanpakissuer, john76:applicant. 
loanpal.ots.com creates an EFT OTM and sends it to the 
TNS, bound for OTS-ID john76. 

[0148] state 14: Refer to Fig 19: john76 receives another RTL. 

This RTL is from loanpal. It contains a link to the Loan. PDF 
issued by loanpal. The roles for Loan. PDF is is- 
suer:loanpal, applicant:john76 

[0149] state 15: Refer to Fig 19: john76 views this transcript and 
'submits' it to www.irsusg.com for a tax rebate, cad- 
enizen.ots.com talks to TNS and gets the reviewer OTS-ID 
as irsusg. It updates the role information for Loan. PDF in 
transfer table for this RTL as issuerloanpal, appli- 
cant:john76, reviewer:irsusg. cadenizen.ots.com creates a 
EFT OTM and sends it to the TNS which forwards the OTM 



to the TS hosting the reviewer OTS-ID irsusg. 
[° 15 °] State 16: Refer to Fig 20: IRS logs in to irsusg.ots.com and 
is recognized as OTS-ID irsusg. It has received a RTL from 
john76 with description "Loan for John Turner", irsusg 
views this document, which causes irsusg.ots.com to send 
view OTMs to OTS-ID john76, cadenizen.ots.com to send 
view OTMs for OTS-ID loanpal, and loanpal.ots.com sends 
a transfer OTM to OTS-ID irsusg that contains the tran- 
script. 

[0151] This example illustrates how transcripts are got directly 

from the issuer using OTS. Applicants or reviewers need 

not store their originals any more. They can directly get it 

on demand from the issuer. Issuer has complete control 

and can stop access to an original transcript any time by 

just deleting that transcript or taking the transcript server 

out of the virtual private transcript network. 
Summary 

[0152] The features addressed by OTS in order to provide effec- 
tive original transcript service are: Availability, Scalability, 
Manageability and Security. 

[0153] Availability: For a transcript to be viewed the transcript 
servers hosting the relevant OTS-IDs must be up and be 
able to talk to the transcript network server. 



[0154] |f a user needs to submit a transcript the user can go to a 
computer connected to the Internet, and log in to the 
user's transcript server and submit an issued transcript to 
the reviewer. The reviewer receives it and views it directly 
from the issuer. 

[0155] issuers have absolute control of a transcript. They can 
delete it or replace it. 

[0156] a view request to a transcript will fail it was deleted by the 
issuer. A view request to a transcript will fetch the latest 
version if it was replaced by the issuer. 

[0157] An issuer deletes a transcript when it is no longer valid. 
An example of this could be a need by an employer to 
delete verification of employment transcript since the em- 
ployee is no longer employed by the employer. 

[0158] An issuer can also replace the document that is invalid 

with a document that is valid. In such cases the document 
need not be issued again. A view request by the applicant 
or reviewer will pick this new transcript. An example of 
this could be a driving license transcript that is replaced 
by DMV after its expiry. 

[0159] since an applicant does not store original transcripts at 
applicant's end, an applicant may still want the previous 
version of the transcript or the deleted transcript. In these 



cases the applicant can request the issuer not to delete a 
transcript or issue a newer version as a new RTL. Alter- 
nately he can use the services of a notary who is regis- 
tered on OTS as a company. 

[0160] | n this option, the applicant can submit the transcript to 
the notary company for review. The notary views the tran- 
script from the issuer. The notary can then act as issuer 
and issue this transcript back to the applicant. 

[0161] Scalability: 

[0162] a large company has many employees. An existing large 
company would already maintain transcripts for employ- 
ees at various locations and means. 

[0163] The advantage of OTS is transcript servers owned by the 
companies can be used to issue transcripts already main- 
tained by the company without actually having to store 
them on the transcript server. The companies can also 
store them if they chose to maintain the transcript on the 
transcript server. This is because the location of a tran- 
script at the issuer is the actual file or a link to another 
destination that is accessible from the transcript server. 
So this link could point to another file in an internal com- 
puter maintained by the company. 

[0164] when a company finds one transcript server insufficient 



due to growth in database table content, then multiple 
transcript servers can work in a proxy configuration. In 
these cases the proxy transcript server acts as the tran- 
script server for the OTS-ID which hides other transcript 
servers behind it. The hidden transcript servers can only 
talk to the proxy, and are not known to TNS. The proxy is 
configured to route RTLs based on the timestamp, in the 
RTL name, to the different transcript servers it hides. This 
distributes the RTL storage across transcript servers 
owned by the company and still maintain a single identity 
for a company on OTS. 

[0165] a transcript network server contains information about all 
OTS-IDs. So there may be a need for the transcript 
provider to maintain more than one transcript network 
server and distribute the load of transcript servers be- 
tween these transcript network servers. With this configu- 
ration a TS will always send an OTM to its assigned TNS. If 
the destination is not known the TNS forwards it to other 
known TNS servers who could know about the destination 
OTS-ID. The OTS-IDs maintained with one TNS should not 
clash with the OTS-IDs maintained in another TNS, when 
more than one TNS belongs to the system. 

[0166] Manageability: 



[0167] The main advantage of OTS applicants and reviewers need 
not store original transcripts, at their end. Issuers can use 
OTS to issue transcripts, and have full control of the tran- 
script. OTS also provides identity information for a tran- 
script of all involved parties. This enables an user to 
search for transcripts based on criteria which include is- 
suer, applicant, reviewer, description, and file names. An 
issuer can readily know to who all a transcript was issued 
to. An applicant can readily know from whom a transcript 
was issued and to who all that transcript was submitted 
to. A reviewer will readily know from whom a transcript 
was received and who the issuer for the transcript is. 

[0168] issuing, receiving, submitting or viewing a original tran- 
script is achieved simply by logging to the user's tran- 
script server. A user even while at a remote location and if 
needed to submit a transcript for review, can log in to the 
user's transcript server through a web browser and submit 
it for review. 

[0169] with OTS users can eliminate e-mailing or snail mailing 

transcripts between an issuer, applicant and reviewer. 
P 1 ™] Security: 

[0171] OTS generates the OTS-ID which is unique for a user and 
ties that user to a transcript server. The OTS-ID is gener- 



ated after a background check done by the transcript 
provider for the user, based on the registration informa- 
tion. 

[0172] This OTS-ID is mapped to the UUID information provided 
by the user during registration. 

[0173] when a transcript is issued or submitted, it is always sent 
to a UUID by the user. For a company this UUID can be a 
company web site name. For an individual the UUID can be 
a SSN number or passport number. 

[0174] Companies own their own transcript servers. Hence they 
have complete control of the transcripts issued by them. 

[0175] a receiver of a transcript who is an applicant or reviewer 
does not store the transcript. When a transcript is viewed 
by the applicant or reviewer the transcript always comes 
from the issuer. When a transcript is viewed by an user, a 
view OTM gets sent to the remote OTS-ID for a remote 
path. The issuer completes the view request only if the re- 
quest comes from an applicant of that transcript. An ap- 
plicant forwards a view request to the issuer only if the 
request comes from a reviewer of that transcript. 

[0176] The transcript provider provides public/private keys for 
each server. The TNS maintains a list of public keys of all 
transcript servers it serves. Each transcript server main- 



tains the public key of the TNS it talks to. When a message 
is sent from a transcript server it is encrypted using the 
transcript server's private key. The TNS finds the source 
host name and gets the matching public key and tries to 
decrypt the message. It then confirms the sender OTS-ID 
in the message is from the same transcript server it re- 
ceived the message from. 

[0177] The TNS then encrypts the message with its private key 
and sends it to the transcript server hosting the destina- 
tion OTS-ID. The receiving transcript server decrypts the 
message with the TNS public key. 

[0178] By following these steps OTS achieves identity security 
and content security for a transcript. 



